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Abstract 

ROOT is an object-oriented C-|—|- framework conceived in the high-energy physics 
(HEP) community, designed for storing and analyzing petabytes of data in an ef¬ 
ficient way. Any instance of a C-|—I- class can be stored into a ROOT file in a 
machine-independent compressed binary format. In ROOT the TTree object con¬ 
tainer is optimized for statistical data analysis over very large data sets by using 
vertical data storage techniques. These containers can span a large number of files 
on local disks, the web, or a number of different shared file systems. In order to an¬ 
alyze this data, the user can chose out of a wide set of mathematical and statistical 
functions, including linear algebra classes, numerical algorithms such as integration 
and minimization, and various methods for performing regression analysis (fitting). 
In particular, the RooFit package allows the user to perform complex data mod¬ 
eling and fitting while the RooStats library provides abstractions and implemen¬ 
tations for advanced statistical tools. Multivariate classification methods based on 
machine learning techniques are available via the TMVA package. A central piece 
in these analysis tools are the histogram classes which provide binning of one- and 
multi-dimensional data. Results can be saved in high-quality graphical formats like 
Postscript and PDF or in bitmap formats like JPG or GIF. The result can also be 
stored into ROOT macros that allow a full recreation and rework of the graphics. 
Users typically create their analysis macros step by step, making use of the inter¬ 
active G-|—|- interpreter CINT, while running over small data samples. Once the 
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development is finished, they can run these macros at full compiled speed over large 
data sets, using on-the-fly compilation, or by creating a stand-alone batch program. 
Finally, if processing farms are available, the user can reduce the execution time 
of intrinsically parallel tasks - e.g. data mining in HEP - by using PROOF, which 
will take care of optimally distributing the work over the available resources in a 
transparent way. 
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LONG WRITE-UP 


1 Introduction 


ROOT is a cross-platform C-I--I- framework for data processing, created at 
CERNp^ Every day, thousands of physicists use ROOT based applications to 
analyze and visualize their data. 


The ROOT project was started in 1995 by Rene Brun and Eons Rademakers 
[T]. It started as a private project and grew to be the officially supported 
LHC analysis toolkit. It is currently developed by a small team with members 
from several laboratories. ROOT benehts from a considerable amount of user 
contributions, both from inside and outside science. This write-up focuses on 
the current status of ROOT, as of version 5.24.00. 


and hgure is used to process both real and simulated data, consisting of 
many events having the same data structure and assumed to be statistically 
independent^] In addition, complementary information is also needed to ana¬ 
lyze the data, for example detector parameters (geometry, read-out powering 
and conhguration, magnetic held maps, etc.) or input settings of the simula¬ 
tion engines. Such values do not change at the event scale. Rather, they have 
a slower evolution that dehnes a much coarser granularity: a run is dehned by 
a set of events with constant setting]^ 


A typical application developed for HEP research (more details in section 11.2 


1.1 Discovering ROOT 


To introduce the ROOT framework, one may follow the typical approach of 
new users and its large collection of libraries and tools, with the help of the 
sketch in hgure [1} For a comprehensive description of ROOT’s features see the 
User’s Guide [ 2 ]. 

Newcomers often start from their own analysis program, running over their 
data (usually stored in ASCII format or accessed through a relational database 

^ European Organization for Nuclear Research, Geneva, Switzerland. 

^ Such independence is very important from the computing point of view, because it 
allows to gain the maximum speed-up by distributing subsets of the data to parallel 
analysis nodes. 

^ In real life, few of the auxiliary parameters may be allowed to vary inside a run. 
Hence, they define smaller blocks that are intermediate between the event scale and 
the run granularity. 
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engine). They simply look for a library to produce graphs to visualize their 
histograms. They start by playing with the ROOT class TGraph, which can 
be used to display a set of (x, y) points including errors. 


for more details) instead, and let the THl::Draw() method produce the plots. 
ROOT histograms can be used for binning a data set and to estimate its 
density. They have a number of useful properties, allowing the user to manip¬ 
ulate them, to obtain statistical information about the underlying data, and 
to perform fits without caring about the plots — they will redraw themselves 
whenever changes are applied. 

Especially during the early phases, when the data analysis program changes 
quite often, the users may find the interactive C-I--I- interpreter CINT embed¬ 
ded in ROOT very useful. Developing programs with the help of an interpreter 
speeds up the typical iterative approach to data analysis by removing the ad¬ 
ditional compile and link steps. Of course, if the logic of the application is 
already well known, one may prefer to develop the program in a more struc¬ 
tured way, relying on the compiler in the usual way. 

The most common task for data access in HEP is the selective, sparse scanning 
of data. Traditional RDBMS-like horizontal data partitioning does not allow 
for efficient sparse reading, with the exception of indices. Instead, ROOT uses 
vertical data partitioning of arbitrary user-defined objects, implemented in its 
TTree class. 

TTreei are partitioned into branches. During reading each branch can be ac¬ 
cessed independently. A TBranch stores consecutive objects or data members 
of a class or other TBranch^s. By default, all branches stored in a TTree are 
written into separate buffers in a file, so that iterating over the data stored in 
a branch requires only the reading of these associated buffers. TTrees can span 
multiple ROOT files. A ROOT file is very similar to a file system, allowing 


The next step is to use ROOT histograms (whose base class is THl, see 12.3 
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for further internal organization using directories. For example, the main data 
set could be stored into a single TTree, whereas summary information (in the 
form of histograms) resides in separate directories in the same TFile. 

If the data volume grows, the user can choose to split the TTree instance 
among several TFile instances. Later, when accessing data, they can all be 
chained into a single logical entity, a TChain, making accessing several hies 
almost transparent. Because a TChain inherits from a TTree, it provides the 
same benehts in terms of optimized data access, even though the data are 
distributed among different hies. 


The quickest way to develop the user’s analysis program is creating ROOT 
macros step by step using Cl NT. Once the development phase has ended, 
performance becomes paramount. The hrst obvious optimization step is to 
convert the application into a compiled program. Still, one does not need to 
abandon the use of the interpreter; the most efficient way to work with ROOT 
is to consider the interpreter as the “glue” which binds together the compiled 
pieces of code that perform most of the intensive computation. Actually, this 
is less difficult than it appears: Cl NT macros can be compiled during the 
interactive session by ACLiC (1 |2.6.2 ), to gain the full speed of compiled code 
and the reliability of the full C++ compiler (ClNT has e.g. limited support of 
C++ templates). In general, interpreted code may call compiled code and vice 
versa (more details on ^2.6 ). Finally, if a multi-core machine or a computing 
farm is available, PROOF ((;2.7) provides a way to make full use of the inherent 
event parallelism of independent HEP events by taking care of distributing the 
analysis over all available CPU’s and disks in a transparent way. 


1.2 Typical Uses of ROOT 


Figure shows most of the features that a ROOT application can have. Of 
course, a single application rarely has all of them: for example, its focus could 
be on the detector simulation or on the data analysis, but not both. 


important HEP simulation engines, like Geant4 [3] (C++), GeantS |1], Fluka 
|5] (FORTRAN), to simulate the passage of particles through matter and 
their propagation in a magnetic held. The VMC interface allows the user to 
build an application that simulates the behavior of a particle detector, with 
the freedom to switch between different simulation engines. Comparing the 
results of different simulation engines allows to estimate systematic simulation 
uncertainties. 


ROOT provides the Virtual Monte-Carlo (VMC) interface ()|2.5 ) to the most 


Usually, most ROOT users develop programs to perform statistical data anal¬ 
ysis (see also ^2.2) of binned (histograms) or un-binned data ( TTree variables). 
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Fig. 2. Example of typical usage of ROOT, 


The TMVA packag^ ( ^2.2[ ) can be used for event classification to discrimi¬ 
nate between signal and background. Various methods exist for performing 
the best hts of the selected data to theoretical models. 


ROOT can also be used to develop an event display §2.4[ An event display is 
an application that provides detector geometry visualization, views of hit^ 
and clusters of hits used to build calorimeter jet^ and physics vectors (4- 
momentsp^. In addition, clusters and physics vectors are used to build tracks 
that visualize the path of particles through the detector. 


2 Description of the ROOT Framework 


The ROOT framework contains about 3000 classes, grouped into about 110 
packages and plugins. In addition, the latter are grouped into top-level cate¬ 
gories that are the subject of this section. 


® http://tmva.sourceforge.net/ 

^ In the HEP jargon, a “hit” is a localized energy deposition that is detected by 
the read-out electronics. 

® A jet is a 3D distribution of energy deposition that is usually well contained by 
a cone (think about a very big elongated drop of water, to visualize it). 

® A four-momentum is a vector of the spacetime whose time-like component is 
(proportional to) the particle energy and the space-like component is the 3D mo¬ 
mentum. 
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Fig. 3. Transient/persistent conversion in ROOT. 
2.1 Input/Output 


ROOT is currently used for storing up to 50 petabytes of data according to the 
latest estimate^ [ The I/O layer stores C++ objects into storage systems, be 
it hie systems, databases, common protocols to storage elements (like xrootd 
|6], dCach^^ or rficp^, or HTTP, see hgure|^ 


2.1.1 Describing C++ Objects 

To be stored, C++ objects need to be described: the I/O must know what 
to store. ROOT provides this description (called dictionary) for all its classes 
and users can build dictionaries for their own classes. The description data 
(commonly called reflection) are provided by Cl NT, or by a combination of 
GCCXML [7] and Reflex, a C++ rehection library that is part of ROOT. Based 
on that information, ROOT knows where in memory an object’s data members 
are, what their size is, and how to store them. ROOT I/O supports pointer 
(un-)swizzling, the conversion of pointers to indexes in the output buffer. It 
can even deal with an object graph with circular references (making sure each 
object is streamed only once to the buffer), and it is able to restore it correctly 
upon reading. 

Because the description of all relevant classes is stored with the data, changes 
of the class dehnition of objects stored with ROOT I/O are supported. When 
reading, the descriptions from the persistent layer and the in-memory ver¬ 
sion are compared: if differences are found, ROOT automatically translates in 
many cases from the old to the new format {schema evolution). A complete 
framework for arbitrary user controlled conversions is also available [8]. 

According to a survey of a number of experiment computing coordinators 

http://www.dcache.org/ 

http://hikwww2.fzk.de/hik/orga/ges/infiniband/rfioib.html 










































2.1.2 TFile 


A ROOT file is read and written by the class TFile and is designed to be write- 
once, read-many (while snpporting deletion and re-use of contained data). 

The content of a ROOT file is a simple binary stream, with a layout described 
in the class documentation of TFile [9]. All data but the header is usually 
compressed to reduce the storage space and I/O bandwidth usage of hies at 
the cost of slightly increased CPU time when reading and writing hies. The 
hie consists of a content index, the list of type descriptions relevant for the 
hie, and the actual data. Each data chunk is named and it can be retrieved 
given its name. TFile also supports hierarchical storage in nested directories. 


Typical hie sizes range from a few kilobytes to several gigabytes. Files can 
be merged into new, larger hies; this can be done recursively, i.e. merging 
also the collections themselves that are contained in the hie, as long as they 
have the same name and are of the same type. Collections of hies can also 
be merged into a zipped container; ROOT supports transparent unzipping of 
and navigation in this collection of hies. 


The description of the classes stored in the hie ( ^2.1.1 ) can be used to read the 
data even without the C-I--I- class dehnition. One can thus write C-I--I- objects 
using the dehnition from a user library, and read them back without the user 
library. Any available rehection data is used to interactively browse a ROOT 
hie using the TBrowser that can also expand and browse the content of all 
C-I--I- objects, either from ROOT or STL, or user dehned. 



2.1.3 TTree and I/O 

A TTree is a container that is optimized for I/O and memory usage. A TTree 
consists of branches, branches can contain complete objects of a given class 
or be split up into sub-branches containing individual data members of the 
original object. This is called splitting and can be done recursively till all 
sub-objects are split into branches only containing individual data members. 
Splitting can even transform containers into branches of the containee’s data 
members, grouping them as shown in Splitting can be done automatically 
using a class’ dictionary information. Each branch stores its data in one or 
more associated buhers on disk. The desired level of splitting depends on the 
typical future access patterns of a tree. If during analysis all data members of 
an object will be accessed then splitting will not be needed. Typical analyses 


9 
















Row Wise Storage 

(e.g. In memory) 


A 

< 

V 


u 

0) 

> 


^ int a1 = 0 
:a2 = 12 
: a3 = -1 


w int 1 
ro 

o int > 


^ int a1 = 0 
:a2 = 11 
: a3 = -1 


w int i 


-S 

o 


int i 


^ int a1 = 0 
w inta2 = 16 
o int a3 = 0 


^ int a1 = 0 

w inta2 = 12 
cc 

o int a3 = 1 


Split Data 


0 


0 

(0 

0 

c 

0 


12 


11 

CM 

<0 

16 

c 

12 


-1 


-1 

CO 

<0 

0 

c 

1 



A 

< 

V 


u 

0) 

> 


Fig. 4. Automatic splitting of a container of objects, 
access only a few data members; in this case splitting is highly beneficial. 

Branch-based storage is called vertical or column-wise storage (CWS; figure]^, 
as opposed to horizontal or row-wise storage (RWS) as is usually found in 
RDBMS databases. In CWS, just like in RWS, a collection (“table”) of similar 
objects (“rows”) is assumed. However, in RWS all data members of an object 
are always read, while in CWS only the needed buffers (e.g. data members) 
are read. Splitting is an automated way to create these columns. 

CWS reduces the number of I/O operations and the amount of transferred 
data, because it reads only the needed parts of each object. All other mem¬ 
bers of the object keep the values defined by the class default constructor. 
When iterating through the collection, data members that need to be read are 
consecutive on the storage medium in the case of CWS. This allows block-wise 
reading of the data for several entries (rows) in one go, something massively fa¬ 
vored by all modern operating systems and storage media. Another advantage 
stems from the fact that ROOT compresses the data buffers using Huffman 
encoding nDi, which benefits from seeing the same byte pattern more often, 
because the same data member usually has similar values (e.g. a particle’s 
type ID). 

Because a TTree describes the objects it contains, one can read objects from a 
TTree even without their original class definition. The TTree can even generate 
a C-I--I- header file representing the layout of the object’s data as stored in the 


allows a smooth transition from stored binary data to C-I--I- objects, even 
without C-|--|- libraries. TTrees can also generate a TSe/ector skeleton ( ^2.7.4 ) 
for data analysis automatically. 


TTree, Combined with the power of the interpreter and ACLiC (1]2.6.2) this 
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Fig. 5. Column-wise layout of TTree data in memory buffers. 


Given the huge amount of data commonly processed by users of ROOT, TTrees 
often do not £t into a single hie, or the file grows to impractical sizes. In addi¬ 
tion, in (parallel) batch system-based analyses, splitting TTrees across several 
hies facilitates the distribution of data. ROOT supports this with TChain, 
by implementing a collection of TFiles that all contain a part of the sam ^ | 
TTree. The TChain inherits from TTree, hence making it irrelevant to the user 
whether the TTree is stored in one or several physical hies. 

Analyses commonly access the same part of a TTree for all its entries. ROOT 
implements an auto-adaptive pre-fetch mechanism reading the next entry 
while the previous entry is still being processed. This reduces the ehect of 
high latency networks dramatically: reasonable sized analyses become viable 
even over ADSL. Tableshows the duration of an example data analysis. The 
280 MB data hie is hosted at CERN with a lOOMbit/sec network connection; 
the analysis reads 6.6 MB. The bandwidth shown is the smallest bandwidth 
found on the connection path. For a low-occupancy connection bandwidth is 
clearly not the limiting factor. 


With identical name and struture. 


11 





































































Location of 

Data Analysis 

Bandwidth 

(Mbit/s) 

Latency 

(ms) 

Analysis CPU 

Duration (s) 

Cache 

0 

size 

64 

(KB) 

10240 

local (no network) 



Pentium4, 2.4 GHz 

3.4 

3.4 

3.4 

CERN 

100 

0.3 

Pentium4, 3 GHz 

8.0 

6.0 

4.0 

CERN wireless 

10 

2.0 

Core Duo, 2 GHz 

12 

5.6 

4.9 

Orsay, France 

100 

11.0 

Pentium4, 3 GHz 

130 

12 

9.0 

Amsterdam, NL 

100 

22.0 

Opteron 280 

230 

12 

8.4 

ADSL 

8 

72.0 

Core Duo, 2 GHz 

740 

48 

28 

Caltech, USA 

10,000 

240.0 

Opteron 280 

> 1,800 

130 

9.9 


Fig. 6. Performance improvements by the TTree cache, see text. 
2 . 1.4 I/O Formats 


ROOT can store via its I/O interface any C++ objects in binary ROOT 
files. It also snpports the XML representation, thongh mostly for didactic 
pnrposes it nicely demonstrates the layont, bnt its performance (dne to 
XML’s ASCII-based representation) and disk nsage (dne to XML’s verbose 
meta-data) prohibits its nsed as a prodnction storage format. 


Data can also be stored into database tables throngh an abstraction layer; 
the description of objects and their member is translated into tables and their 
colnmns. 


2.2 Mathematical and Statistical Tools 


One may need to manipnlate data in a nnmber of different ways. Becanse 
ROOT is a C++ framework, all C and C++ standard fnnctions are avail¬ 
able. In addition, ROOT provides a nnmber of advanced mathematical and 
statistical fnnctions, well integrated into the framework, that allow to perform 
virtnally all possible operations with a few simple commands. 

The minimal set of tools reqnired for nnmerical compnting is provided by the 
MathCore library. It consists of the following components. 

• Commonly nsed mathematical fnnctions like special fnnctions not provided 
yet by the C++ standard and statistical distribntion fnnctions. For each 
statistical distribntion, the probability density, the cnmnlative and its in¬ 
verse fnnctions are provided. These fnnctions are provided in the namespaces 
ROOT: :Math and TMath. 

This format has been implemented originally as an exchange format with non 
ROOT based applications, but only a few applications have made use of it. 
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• Classes for random number generations {TRandom classes). The default 
pseudo-random number generator is the Mersenne and Twister generator 
( TRandoms class) [TT] . 

• Basic implementation and interfaces of numerical algorithms, like integra¬ 
tion, derivation or simple (one dimensional) minimization. 

• Classes and interfaces required for htting all the ROOT data objects. 

• Abstract interfaces and adapter classes for function evaluation in one or 
more dimensions. 

The Math More library complements MathCore by providing additional math¬ 
ematical functionality. It is based on the GNU Scientihc Library (GSL) |T2], 
which is used as an external library. Math More implements extra special func¬ 
tions like Bessel functions of various types and fractional order, elliptic inte¬ 
grals, Laguerre and Legendre polynomials, hypergeometric functions. Math- 
More contains additional implementations of the numerical algorithms and 
extra random number generators which are present in GSL. 

Various libraries exist for numerical minimization and fitting. These libraries 
include the numerical methods for solving the fitting problem by finding min¬ 
imum of multi-dimensional functions. A common interface exists in MathCore 
(the class ROOT: :Math: : Minimizer) for multi-dimensional numerical minimiza¬ 
tion. Several implementations of this interface are present in ROOT: 

• Minuit provides an implementation of the popular MINUIT minimization 
package na. It is a direct translation from the original Fortran code to 
C-|—|- and provides a very similar API. 

• Minuit2 is a completely new objected-oriented implementation of MINUIT 
|14j . The same minimization algorithms like Migrad and Simplex are present, 
but with new objected-oriented interfaces. Furthermore, it provides an im¬ 
plementation of a specialized method for finding the minimum of a standard 
least-square or likelihood functions, by linearizing the Hessian matrix. This 
algorithm is called in ROOT Fumih2. 

• Fumili: library providing the implementation of the Fumili htting algorithm|15j. 
another specialized minimization method for least-square or likelihood func¬ 
tions. 

• Math More offers minimizers based on GSL. These include various mini¬ 
mization methods based on conjugate gradient algorithms, the Levenberg- 
Marquardt algorithm [15] for non-linear least-squares htting and a stochastic 
minimization method based on simulated annealing. 

• The TLinearFitter class implements linear least-squares htting with a possi¬ 
bility for using robust htting. 

ROOT contains two libraries providing matrices and vector classes and linear 
algebra operations: 


13 




• Matrix: general matrix package including matrix TMatrix and vector TVector 
classes and the complete environment to perform linear algebra calculations, 
like equation solving and eigenvalue decompositions. 

• SMatrix: package optimized for high performance matrix and vector com¬ 
putations of small and hxed size. It is based on expression templates to 
achieve a high level optimization and to minimize memory allocation in 
matrix operations. It derives from a package originally developed for HeraB 
mi. Performance studies of the matrix packages in benchmark applications 
used in HEP have been shown elsewhere |18j . 

Two libraries exist in ROOT also for describing physics vectors in 2, 3 and 4 

dimensions (relativistic vectors) with rotation and transformation algorithms: 

• Physics: library with the TVectorS and TLorentzVector classes. 

• GenVector: package with generic class templates for modeling geometric vec¬ 
tors in 2 and 3 dimensions and Lorentz vectors. The user may control how 
the vector is internally represented, by making a choice of coordinate system 
and underlying scalar type. 

Other mathematical and statistical packages in ROOT are: 

• Unuran: universal algorithms for generating non-uniform pseudo-random 
numbers, from a large set of classes of continuous or discrete distributions 
in one or several dimension^3E] 

• Foam: multi-dimensional general purpose Monte Carlo event generator (and 
integrator). It randomly generates points (vectors) according to an arbitrary 
probability distribution in n dimensions. [12] 

• FFTW: library with implementation of the fast Fourier transform (FFT) 
using the FFTW packag^^^ It requires a previous installation of FFTW. 

• MLP: library with the neural network class, TMultiLayerPerceptron based on 
the NN algorithm from the mipfit packag^^^ 

• Quadp: optimization library with linear and quadratic programming meth¬ 
ods. It is based on the Matrix package. 

• Statistic classes for computing limits and confidence levels. Some of these 
classes are currently provided by libPhysics. 

• TMVA: toolkit for multivariate data analysis, providing machine learning 
environment for the processing and parallel evaluation of sophisticated mul¬ 
tivariate classihcation techniques. Though specihcally designed to the needs 
of high-energy physics applications, it offers general methods that can be 
used in other helds, too EOI- 

• RooFit: toolkit for modeling statistical distributions (especially the ones 
used in physics analysis). Models can be used to perform likelihood hts. 


15 

http://statmath.wu-wien.ac.at/unuran/ 
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The “Fastest Fourier Transform in the West’ 

5 

http://www.fftw.org/ 

17 

http://schwind.web.cern.ch/schwind/MLPfit.html 
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produce plots, and generate “toy Monte Carlo” samples for various studies 

izu. 

• RooStats: package providing the required advanced statistical tools needed 
by the LHC experiments for their hnal data analysis in order to calculate 
conhdence intervals, to perform hypothesis tests and combinations of differ¬ 
ent analysis channels. It provides common interfaces to the major tools with 
implementations based on different statistical techniques, which have been 
approved by the experiment statistical committees. It is based on the RooFit 
classes for describing probability density functions or likelihood functions. 


2.3 Histograms 


When dealing with many events, one usually adopts statistical methods to 
analyze them. Two different approaches are possible: statistical data analy¬ 
sis of binned or unbinned data. The most frequently used approach involves 
binned data, in the form of histograms, whereas unbinned data are saved into 
instances of the TTree class (see 12.1.3). 


In ROOT, 1-dimensional histograms are dehned by the base class THl: actual 
classes inherit from THl with the type of the bin count (char, float, dou¬ 
ble,...) dehned by the derived class. THl is also the base class for 2D and 3D 
histograms (again, supporting different types of entries) and for prohle his¬ 
tograms {TProfile, TProfile2D and TProfile3D). Prohle histograms are used to 
display the mean value of a variable and its standard deviation in each bin of 
another dependent variable (or variables in case of multi-dimensional prohle 
histograms). Histogram classes can also be used to analyze weighted data sets. 


ROOT histograms internally contain a pair (value, uncertainty) for each bin, 
plus the numbers of entries which fall outside its limits (both overhow and un- 
derhow). Additional information like the total number of entries and the inte¬ 
gral of the histogram are also stored. Statistical information such as the mean 
and standard deviation along the histogram axis can be obtained. The bin¬ 
ning can be dehned with constant or variable step size and higher-dimensional 
histograms support projecting and slicing. Histograms can also be htted with 
a user provided function. 


Many types of operations are supported on histograms or between histograms: 
addition and subtraction, multiplication and division with histograms, func¬ 
tions, or scalars. They can also be rebinned and compared using statistical 
hypothesis tests like the chi-square test. 


Histograms can be plotted by invoking the Draw() method and the result can 
be interactively manipulated (see ^2.4). Labels can be numerical or textual 
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and the user can define title; 
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for the histogram and each axis. 


Sets of (x, y) or (x, y, z) data can be displayed and analyzed in ROOT using 
the TGraph or TGraph2D classes. The data errors can also be displayed using 
the derived classes TGraphErrors and TGraphAsymErrors. In addition to fitting, 
the TGraph classes provide the functionality for interpolating the data points 
using different techniques such as cubic splines and for smoothing. 


ROOT allows the user to fit both binned and unbinned data with paramet¬ 
ric functions which can be displayed together with the data. The plottable 
functions are represented by the classes TEl TE2 or TE3 depending on the di¬ 
mension. They can be created either from precompiled user code, using global 
functions or class member functions or from mathematical expressions which 
are handled by the TEormula class. TEormula is able to parse expressions con¬ 
taining mathematical functions, including those in TMath and using a special 
syntax for defining the parameters. Predefined expression representing func¬ 
tions like polynomial, Gaussians, exponential or Landau are also available to 
facilitate the usage. 


In addition to invoking the Fit() method from a macro, the user can also 
make use of the GUI provided by the fit panel (figure during interactive 
sessions. It can be opened directly from the ROOT TGanvas menu or via the 
context menu of any ROOT object which is suitable for fitting, available after 
a right mouse click on the object. With the fit panel, the user can select the 
fit function, set the initial parameter and control all the available fit options. 
It offers also the possibility to draw scan plots and contour plots of the fitted 
parameters. 


2.4 Graphics and User Interface 


Whenever ROOT draws an object, it puts it into a TGanvas instance, repre¬ 
senting an area mapped to a window directly under the control of the display 
manager. One can save the TGanvas into several possible formats: for standard 
graphics formats, publication quality is obtained by means of vector graphics 
like PostScript or PDF, but raster graphics is usually a better choice for images 
to be included into web pages. One can also store it as a G-I--I- macro where 
the G-I--I- statements reproduce the state of the TGanvas and its contents. This 
allows complete reproduction from within ROOT, 

Of course, we can open multiple canvases if we want to display different things, 
but it is often better to organize everything into a single TGanvas. For this 
reason, a TGanvas instance can be subdivided into independent graphical ar- 

DTRX-like strings are supported. 
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Fig. 7. The ROOT fit panel: the General tab (left) for selecting function, fit methods 
and options, the Set Parameter dialog (up right) for setting initial values and limits, 
and the Minimization tab (bottom right) for selecting the minimization library and 
method. 


Original function with Graph2D points on top 




MiniiiH|t^esulton the Graph2D^ointe^^| 




Fig. 8. Example of graphical output. The canvas contains 6 pads. 

eas, called “pads” (by default, a canvas contains a single pad, occupying the 
whole space — TCanvas inherits from TPad), as shown in hgure|^ 

All ROOT classes inheriting from TObject can be displayed on a pad with the 
Draw() method. Graphical object sizes are usually expressed in user coordi- 
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nates. For instance, after a histogram or a graph has been drawn, the user 
coordinates coincide with those dehned by the plot axes. The pad position 
in its parent pad is expressed in normalized coordinates, in which the pad is 
mapped to a unit rectangle. The TCanvas requires dimensions in pixels to be 
positioned on the desktop. 

In ROOT, the Draw() method does not actually draw the object itself. Rather, 
it adds the object to the display list of the pad (so that it gets drawn every time 
the pad is redrawn) and invokes the Paint() method, that draws the actual 
graphics primitives. ROOT manages the repainting of the TCanvas automati¬ 
cally when either the object is updated of the operating system requires. 

Every ROOT object drawn on a pad can be edited interactively. In addition 
to the pop-up editor (opened from the menu obtained by right-clicking on any 
object), each canvas can also host an editor (opened by selecting “Editor” 
from the “View” menu provided by the window). To modify any object shown 
by the canvas, simply open the latter editor and click on the object. 


2.4-1 2D Graphics 

2D graphics include everything we can display on the monitor or print on 
paper. ROOT needs to be interfaced with the operating system’s graphics 
engine, in order to be able to display windows containing some plot, for ex¬ 
ample. ROOT uses the XI1 graphics engine on unix-like systems and Win32 
on Windows, but can also use the multi-platform Qt librar} p^ 

Through the libAfterlmage librarj^^ ROOT is also able to load bitmap 
images and to manipulate them. This package also allows to produce bitmap 
output hies in all common formats such as GIF, PNG, JPEG, etc. 


2 . 4.2 3D Graphics 

There are several ways to render 3D graphics in ROOT, the preferred one using 
the OpenGL p^ graphics library, which is used in ROOT to display data using 
lego and surface plots and to render detector geometries. Work is in progress to 
also use it for 2D graphics and thus have a single, portable rendering interface 
for 2D and 3D screen graphics. 


19 Originally provided by Trolltech, that was renamed to Qt Software (http://www. 
qtsoftware.com/) after acquisition by Nokia in 2008. 
http://www.afterstep.org/afterimage/ 
http://WWW.opengl.org/ 
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2.4-3 Geometry and Event Display 

Geometry in the 3D space is described in ROOT by means of basic solids 
that can be joined, intersected or subtracted to create more complex shapes. 
The possibility to visualize 3D objects is very important. ROOT implements 
its own scene-graph management library and rendering engine that provides 
advanced visualization features and real-time animations. OpenGL library is 
used for actual rendering. 

Event display programs are an important application of 3D visualization. 
EVE, the event visualization environment of ROOT, uses extensively its data- 
processing, GUI and OpenGL interfaces. EVE can serve as a framework for 
object management offering hierarchical data organization, object interaction 
and visualization via GUI and OpenGL representations and automatic cre¬ 
ation of 2D projected views. On the other hand, it can serve as a toolkit 
satisfying most HEP requirements, allowing visualization of geometry, sim¬ 
ulated and reconstructed data such as hits, clusters, tracks and calorimeter 
information. Special classes are available for visualization of raw-data and 
detector response. EVE is used in the ALIGE p^ experiment as the standard 
visualization tool, AliEVE (hgurej^, using the full feature set of the environ¬ 
ment. In the GM^^ experiment, EVE is used as the underlying toolkit of the 
cmsShow physics-analysis oriented event-display. Both AliEVE and cmsShow 
are also used for the online data-quality monitoring. 


2 . 4.4 Graphical User Interface 

The ROOT Graphical User Interface (GUI) integrates typical GUI functional¬ 
ity with ROOT features, like storing the GUI as G-I--I- source, interpreted GUI 
via CINT and CINT-based signal/slot communication. The result is a flexible 
GUI toolkit, rich of functionalities and offering all widgets that are provided 
by other toolkits, including a GUI buildeip^ 

The ROOT GUI builder provides tools for developing user interfaces based on 
the ROOT GUI classes. It offers a palette of user interface elements. They can 
be selected, positioned, and grouped, laid out in the main application frame. 
According to the selected widget, a dynamically created context menu provides 
detailed control of widget attribute settings. One can save on a ROOT macro 
the result, and take such G-I--I- code as starting point for further developments. 


http://aliceinfo.cern.ch/Public/Welcome.html 
http://cms.web.cern.ch/cms/index.html 

The development of a dedicated ROOT GUI was required because when the 
project started there were no good cross platform toolkit; Qt existed but had license 
problems. 
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Fig. 9. Screenshot of AliEVE showing a simulated proton-proton event at the LHC 
collider as seen by the ALICE detector. The reconstructed particle trajectories are 
shown as black lines and the measured particle passage-points as colored dots. 

2.5 Simulation 


TVirtualMC provides a virtual interface to Monte Carlo applications, allowing 
the user to build a simulation independent of any actual underlying Monte 
Carlo implementation itself. A user will have to implement a class derived 
from the abstract Monte Carlo application class, and provide functions like 
ConstructGeometryQ, BeginEvent(), FinishEvent(), ... The concrete Monte 
Carlo implementation (GeantS, Geant4, Fluka) is selected at run time — when 
processing a ROOT macro where the concrete Monte Carlo object is instan¬ 
tiated. This allows for comparison between different engines (often used to 
estimate the systematic simulation uncertainties) using a single application. 
ROOT thus offers a single interface common to all of the most common simula¬ 
tion engines; it offers a centrally managed, performant C-I--I- geometry system 
instead of a plethora of different, often incompatible and too specialized ge¬ 
ometry systems as provided by the simulation engines. Its geometry system 
offers I/O capabilities and an interface to ROOT’S event display. Examples of 
VMC can be found in AhROOT[28] for the ALICE experiment at the LHC or 
EAIRROOT[29] for the FAIR experiments at GSI, Darmstadt. 

Monte Carlo simulations always have to describe the input particles, together 
with their interactions, and the detector (geometry, materials and read-out 
electronics). The definition of particles, available interactions and detector 
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is done during the initialization phase. The main body of the application 
is then a loop over all particles that are traced through all materials until 
they exit, stop or disappear (by decay or annihilation). The tracing is done 
in a discrete fashion: at each step, the detector volume is found in which the 
particle is located and pseudo-random numbers are used to “draw” one among 
possibly several physical processes, to simulate the interaction of the particle 
with the matter. If an interaction occurs, the energy lost by the particle is 
computed (again, it is usually a random process) and subtracted from its 
kinetic energy. When the latter reaches zero, the particle stops, otherwise a 
new step is performed. 

Having computed the energy lost by all particles inside the detector, one has 
to simulate the behavior of the read-out electronics. This is usually done later, 
with another program that receives the energy lost in different locations as 
input, but it can also be done by the very same application that is performing 
the particle tracing inside the detector. Usually, the simulation of the read¬ 
out electronics also involves some use of pseudo-random generators, at least 
to simulate the hnite resolution of any real measuring device. 

In any detector simulation, the dehnition of its geometry has special impor¬ 
tance. The ROOT geometry package is a tool to build, browse and visualize 
detector geometries. It is independent from any Monte Carlo simulation en¬ 
gine, though it has been designed to optimize particle transport in correlation 
with simulation packages as GeantS, Geant4 and Fluka. 

Most detectors in HEP have been modelled with the ROOT geometry (exper¬ 
iments at LEP, LHC, FNAL, HERA, GSI, etc.). For example, the standard 
ROOT test suite tracks particles to 35 large detectors. The Geometry De¬ 
scription Markup Language (GDML)p^ system can be used to export/import 
geometries from/to other formats (e.g. GeantS, Geant4). 

The building blocks of any geometry are the volumes. Volumes may contain 
other volumes, producing a hierarchy of volumes. The biggest one, called the 
“world”, contains all other volumes and provides the master reference system 
(MARS) in which the others are positioned. Each volume (except for the 
’’world”) needs to be associated with a medium, that can be a mixture of 
different materials (whose weights are the relative densities). 

Gomplex geometries can be built in a hierarchical way, through the concept of 
containment: one has to dehne and position some volumes inside other ones. 
Positioning is done with spatial transformations with respect to the “mother 
reference system” (i.e. the system defined by the containing volume). Gomplex 
volumes are built using basic or primitive shapes, already dehned by ROOT 
(e.g. box, tube, cone, etc.), through operations like join or subtract. Finally, 

http://gdml.web.cern.ch/GDML/ 
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a given volume can be positioned several times in the geometry or it can 
be divided accordingly to user-defined patterns, automatically defining new- 
contained volumes. 

Once a geometry has been created, it can be saved into a ROOT file or as C-I--I- 
macro with the Export() method of TGeoManager. Loading the geometry is 
done with its Import() method. In addition, individual volumes can also be 
saved into a ROOT file. Finally, ROOT provides a graphical user interface to 
edit or build a geometry. The editor can be opened with the Edit() method of 
TGeoManager, 

Having defined the detector geometry, particles need to be tracked inside all 
volumes, and their interaction simulated. The application can make use of 
the ROOT geometry package to build a detector and the virtual Monte Carlo 
interface to access one or more simulation engines. ROOT makes it possible 
also to store and visualize tracks, as it is done inside the drawing package with 
the TGeoTrack class. 


2.6 Interpreters 


CINT is an almost full ANSI compliant C/C-I--I- interpreter. It serves as ROOT’S 
non-graphical user interface, both for interactive use (through Cl NT’s prompt) 
and in headless “batch” mode, where CINT processes C-I--I- code without show¬ 


ing any graphics. Other use cases are shown in 12.6.1 


In most cases, physicists develop data analysis programs gradually, through 
repeated cycles of changing and running the code. Traditionally, the code 
needed to be compiled, linked, loaded, and then again unloaded so the next 
iteration could be started. The ability to use an interpreter is a fundamental 
improvement for this approach of rapid development. 


CINT allows interpreted and compiled code to interact: it can call compiled 
code just like it can be called from compiled code, in a re-entrant way. With 
that, code like histograin->Draw() can be interpreted, resulting in the func¬ 
tion THl: :Draw() in one of ROOT’s libraries being called. On the other hand, 
compiled code can contain the statement gROOT->ProcessLine ("myobj->Go ()' 
which could execute the interpreted function MyObj : :Go(). The transition of 
the call chain from interpreted to compiled code happens through stubs; CINT 
keeps a function pointer to the stub for each function that can be called from 


the interpreter. The stubs are generated as part of the dictionary, see (2.1.1 


), 


ROOT also provides the Python interface PyROOT[23] that uses some of CINT 
features. This allows it to do dynamic call translation instead of relying on a 
fixed wrapper. Also provided is an interface to Ruby. Python and Ruby offer 
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late binding and an easy to learn syntax. For a C++ framework, the major 
advantage of providing a C++ interpreter (e.g. compared with a Python inter¬ 
preter) is the homogeneity of languages: users write compiled and interpreted 
code in the same language, they can transfer code or parts of it from the 
interpreted “world” to the compiled one without any transition. 


2.6.1 Interpreter Use Cases 

While interpreters’ use cases are virtually unlimited, there are several key ex¬ 
amples of use already in ROOT’S context. The graphical user interface imple¬ 
ments the signal slot mechanism through the interpreter: the signal is emitted 
as strings interpreted by the interpreter, which are evaluated dynamically. 
This allows powerful expressions and loose coupling between the caller and 
the callee, because the called function does not need to be resolved at link 
time. 

Another use case is ROOT’S auto-documentation component: it parses sources 
on demand, extracting documentation strings. It can even interpret code that 
is embedded in the documentation, run it, and embed the output and the code 
into the documentation. This is an elegant way of keeping graphical output 
up to date and of showing examples of use for the documented class. 

As already mentioned for signal/slot, the interpreter allows a loose coupling 
of libraries through strings resolved at runtime, instead of symbols resolved 
at link time. ROOT makes use of this feature for its plugin manager: instead 
of hard-wiring dependencies or implementations of interfaces at link time, 
ROOT determines the plugin to use at run time, by executing a registered 
piece of C++ code that will instantiate the plugin. This approach is dynamic 
and extensible, eeven by the user. It saves resources because it does not load 
unused plugins. 

ROOT even relies on Cl NT for some parts of the I/O framework: the inter¬ 
preter allows ROOT to call a helper function on an object given only its 
memory address and type name. This, too, is an ideal use case for an inter¬ 
preter. 


2.6.2 Automatic Library Builds 


Interpreting code is always slower than compiled code. Once code has been 
developed it should thus be “moved into the compiled world” and the transi¬ 
tioning of code should be seamless. But it is not: code needs to be compiled, 
linked, and loaded. ROOT’S serialization framework and the interpreter re¬ 
quire an additional build step, see 1 2.1.1 For that, the interpreter scans the 
user’s header files and generates a source file containing the dictionary. These 
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dictionaries, too, need to be compiled, linked, and loaded. 

Tracking of dependencies is a common request, to only update the binary if 
a relevant source file has been changed. Traditionally, users would write a 
Makehle to compile the code which they then link into a binary, either into 
a shared library to be loaded into ROOT, or into a stand-alone executable. 
This is a symptom that the migration of code from the interpreter to a binary 
is far from smooth. 

ROOT removes this hurdle altogether, by completely hiding the complexity 
from the user. To load the source hie myCode. cxx into the interpreter, one 
would usually call 

.L myCode.cxx 

This hle’s functions and types are then available for interpretation. 

To instead load the hie as a shared library, and if needed to build it on the 
hy, users issue this command: 

.L myCode.cxx+ 

This invokes an integrated build system called ACLiC that works on all sup¬ 
ported platforms. It is a powerful replacement for external build systems hiding 
all of the build complexity. Multiple source hies can be compiled into a library 
by including them in a wrapper source hie. 

The smooth transition from interpreted to compiled code ohered by ACLiC has 
been so successful that ROOT is now considering the implementation of true 
just-in-time compilation made possible e.g. though LLVM [2l], [25], instead 
of the invocation of external tools through ACLiC. 


2.1 Parallel Processing Using PROOF 


The Parallel ROOT Facility, PROOF [26], is an extension of ROOT enabling 
interactive analysis of large sets of ROOT hies in parallel on clusters of com¬ 
puters or many-core machines. More generally PROOF can parallelize the class 
of tasks for which solutions can be formulated as a set of independent sub-tasks 
{embarrassingly or ideally parallel). 

The main design goals for the PROOF system are: 

• Transparency: there should be as little diherence as possible between a 
local ROOT based analysis session and a remote parallel PROOF session. 
Typically analysis macros should work unchanged. 
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• Scalability: the basic architecture should not put any implicit limitations 
on the number of computers that can be used in parallel. 

• Adaptability: the system should be able to adapt itself to variations in the 
remote environment (changing load on the cluster nodes, network interrup¬ 
tions, etc.). 

PROOF is primarily meant as an alternative to batch systems for Central 
Analysis Facilities and departmental work groups (Tier-2’s and Tier-3’s [27j l 
in particle physics experiments. However, thanks to a multi-tier architecture 
allowing multiple levels of masters, it can be easily adapted to a wide range 
of virtual clusters distributed over geographically separated domains and het¬ 
erogeneous machines (GRID’s). 

The PROOF technology has also proven to be very efficient in exploiting all 
the CPU’s provided by many-core processors. A dedicated version of PROOF, 
PROOF-Lite, provides an out-of-the-box solution to take full advantage of the 
additional cores available in today desktops or laptops. 

Apart from the pure interactive mode, PROOF has also an interactive-batch 
mode. With interactive-batch the user can start very long running queries, 
disconnect the client and at any time, any location and from any computer 
reconnect to the query to monitor its progress or retrieve the possibly interme¬ 
diate results. This feature gives it a distinct advantage over purely batch based 
solutions, that only provide an answer once all sub-jobs have been hnished and 
merged. 


2.7.1 PROOF Architecture 


The PROOF system is implemented using a multi-tier architecture as shown 


in hgure 10 


The client is the user that wants to use the resources to perform a task. 
The master is the entry point to the computing facility: it parses the client 
requests, it distributes the work to the workers, it collects and merges the 
results. The master tier can be multi-layered. This allows, for example, to 
federate geographically separated clusters by optimizing the access to auxiliary 
resources, like mass storage systems (MSS). It also allows to distribute the 
distribution and merging work, which could otherwise become the bottle-neck 
in the case of many workers. 


PROOF-Lite, the version of PROOF dedicated to multicore desktops, imple¬ 
ments a two-tier architecture where the master is merged into the client, the 
latter being in direct control of the workers. 
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Fig. 10. PROOF multi-tier master-worker architecture. 
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Fig. 11. Schematic view of the PROOF workflow. 
R7.^ Event Level Parallelism 


One of the ideas behind PROOF is to minimize the execntion time by having 
all contribnting workers terminating their assigned tasks at the same time. 
This is achieved by using hne-grained work distribution, where the amount 
of work assigned to a worker, is adapted dynamically following the real-time 
performance of each worker. In principle, the packet can be as small as the 
basic unit, the event. 


A schematic view of the execution flow is given in hgure 11 
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Fig. 12. The PROOF packetizer distributes the work. 
2. 7 .3 The Packetizer 


The packetizer is responsible for load balancing a job between the workers 
assigned to it. It decides where each piece of work - called a packet - should 
be processed. An instance of the packetizer is created on the master node. In 
case of a multi-master conhguration, there is one packetizer created for each 
of the sub-masters. 

The performance of the workers can vary signihcantly as well as the hie data 
transfer rates (local or remote hies). In order to dynamically balance the work 
distribution, PROOF uses a “pull architecture”: when workers are ready for 


further processing they ask the packetizer for a next packet, see hgure 12 


The packetizer uses a worker’s processing rate to determine the size of the 
next packet for that worker. The packetizer tries to size all packets such that 
all workers will end at about the same time. At the beginning of a query the 
packets will be small, to quickly get an idea of the performance of the workers. 
Then the packet size will be increased to allow optimal disk access patterns 
(avoiding small reads) and to best suite the workers CPU performance. 


2 . 7.4 The Selector Framework 

To be able to perform event-level parallelism, PROOF needs to be in charge 
of the event-loop, i.e. the execution how steering the job. This requires that 
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the code to be executed must have a predehned, though flexible structure. In 
ROOT this is provided by the Selector framework, defined by the abstract 
class TSelector, which defines three logical steps: 

(1) Begin, where the job definition (parameters, input data, outputs) is given; 
executed on the client and the workers; 

(2) Process, where the actual job is done; called for each event, on the work¬ 
ers; 

(3) Terminate, where the results are Anally manipulated (fitted, visualized, 
etc.); called on the client and the workers. 

Process is the part that can be parallelized for the class of problems addressed 

by PROOF. 


2. 7 .5 Aggregation of Results 

PROOF has a powerful feature that complements the use of the TSelector 
framework. After each worker has executed the Terminate method described 
above, it sends the set of named results back to its master. The master collects 
these intermediate results and aggregates them depending on their type. For 
several common types, like for example histograms, there is a natural way 
to combine these results. The histogram obtained by adding all intermediate 
histograms together is identical to the one that would have resulted from a 
single worker processing all events. Similarly, event lists can be aggregated etc. 
PROOF uses a well defined API for this process allowing user defined classes 
to make use of this feature. Intermediate results that cannot be combined are 
returned ”as is” in a single collection for each resulting object. 


2.7.6 Real Time Monitoring and Feedback 

The user can monitor the progress of a PROOF query or job in a number of 
different ways. A widget shows the number of events and files processed, the 
% completed and the estimated time to completion. This feedback is useful to 
get a high level idea of the behavior and performance of the PROOF system 
and its underlying components. 

If the user registered histograms in the Begin method of the TSelector class, 
PROOF can show these histograms, updating dynamically, during the running 
of the query. This feature allows the progress of the query to be monitored 
in detail, especially if a very large data-set is being processed. The dynami¬ 
cally updating display is also very effective in educational and demonstration 
settings. 




3 Installation Instructions 


ROOT can be build from source on all supported platforms using the well 
known Open Source tools like Subversion, configure and make. 


3.1 Getting the Source 


The ROOT source tar-ball can be obtained via ftp: 

$ ftp root.cern.ch 
User: anonymous 

Password: <your-email-address> 
ftp> cd root 
ftp> bin 

ftp> get root_<version>.source.tar.gz 
ftp> bye 

gzip -dc root_<version>.source.tar.gz | tar -xf - 

Alternatively the source can be obtained directly from the public Subversion 
repository: 

svn CO http://root.cern.ch/svn/root/trunk root 
A specihc tag can be obtained using: 

svn CO http://root.cern.ch/svn/root/tags/v5-24-00 root-52400 


3.2 Compiling 


Compiling ROOT is just a matter of: 

$ ./configure 
$ make 

The . /conf igure script will discover the platform and check for the existence 
of third party libraries needed for a number of optional plugins. To see all 
available options do: 

$ ./configure —help 

For a complete description of the build procedure see the ROOT web site. 
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4 Test Run Description 


After installing ROOT one can find a large set of test programs in the tutorials 
and test directories. The test programs in the tutorials directory are all 
in the form of macro’s that can be either rnn via the Cl NT interpreter or 
compiled via ACLiC. A standard test macro is benchmarks. C that can be rnn 
via: 

$ cd tutorials 
$ root 

root [0] .X benchmarks.C 
root [1] .q 

If ROOT is properly installed this macro shonld hnish withont errors and 
report a ROOTMARKS nnmber: 

* Your machine is estimated at 1120.18 ROOTMARKS * 

The programs in the test directory are all stand-alone programs that are 
bnild by rnnning make, like: 

$ cd test 
$ make 

This will compile a nnmber of “demo” programs like, guitest, threads, etc. 
and “stress” programs, like stress, stressGeometry, stressGraphics, etc. 
All “stress” programs will also retnrn a performance ROOTMARKS nnmber, 
like: 

$ ./stress -b 30 


* ROOTMARKS =859.2 * Root5.23/03 20090226/1824 
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